Operating facilities have a need for a system and process for exchanging and updating data and relationships within data-driven schematics and various data management systems within an operating facility. There is a need for integration of plant data management systems with data-driven schematics, such as piping and instrumentation diagram (P&ID), process flow diagrams (PFDs) and isometric drawings. A graphical user interface to support such plant data management is particularly challenging, as numerous plant disciplines are involved and are accustomed to applications that are customized to meet specific, disciplinary needs.
Historically, plant operations have been separated into several professional disciplines with employees who offer specific expertise and focus to achieve operational safety, regulatory compliance and profitability. The systems and processes that collect data and information relating to various plant disciplines have been inherently disconnected from one to the other because of separation in responsibilities. Furthermore, each plant discipline has, over time, implemented systems and tools, both hard-copy and electronic, to fulfill discipline-specific objectives and data collection, as well as to communicate requirements that impact other plant disciplines. As electronic data collection systems have improved in both functionality and speed, operating plants have implemented technology initiatives to improve data collection, reporting, and sharing amongst plant disciplines.
For example, several operating facilities have implemented enterprise asset management (EAM) systems, such as SAP®, which have both integrated software and consolidated data applications that become obsolete when data is electronically integrated. Although SAP® may collect data from various sources and can be configured to perform calculations and generate reports, it is not designed to both share and update between a transmitting and receiving database. Accordingly, the graphical user interface (GUI) for an EAM system is generally an application-specific portal that enables users to log-in, view, and generate computational calculations and reports. That is, there is no common user interface to access data stored in an EAM system other than within the “front-end” of the EAM application itself. The standard data model for plants who have implemented an EAM causes challenges to plant disciplines who infrequently use SAP® because the information contained within SAP® is only viewable to plant disciplines from the application-specific “front-end.”
This lack of integration and interoperability is particularly problematic for plant disciplines having responsibilities that impact another department, or which have been impacted by another department.
For example, a plant engineer who is responding to a catastrophic emergency will have several responsibilities after the emergency to perform a root cause analysis as well as make recommendations to prevent a similar occurrence in the future. To properly perform such root cause analyses, a plant engineer will identify a specific location within the process where the catastrophic emergency occurred by utilizing plant schematic diagrams, such as a piping and instrumentation drawing (P&ID), typically formatted in a computer-aided design (CAD) format, such as AutoCAD®. After the process location has been identified, including specific equipment, pipes, and instrumentation (i.e., transmitters of temperature, pressure, and flow measurements), then the engineer will utilize a separate and distinct application, referred to as a process data historian, typically formatted in a database and exportable to Microsoft Excel™, in order to query data in the vicinity of the affected equipment. Analysis of the queried data is then typically compared against another dataset of design parameters, which are housed in another distinct application, typical formats include a variety of hard-copy paper and electronic documents in various databases. If analysis of operating and design data provides insufficient details to perform the root cause analysis, then the plant engineer may inquire with numerous, other plant disciplines to obtain other data including but not limited to operating procedures, inspection, monitoring, and maintenance repair data. It is commonplace in the industry to have separate and distinct databases that manage inspection, monitoring, maintenance repair, and other relevant datasets.
The overarching challenges presented by facility systems in the above example are two-fold: First, how can data collected within a single plant data system, which is separate and distinct from any other, be shared amongst multiple plant disciplines in both “read” and “write” format? Second, what type of GUI can be employed to logically present data that, in its standard format, is limited to being viewed from within each application-specific “front-end.” These issues are not mutually exclusive; that is, to provide a solution to one or the other does not provide an adequate technical basis for solving the challenge of enabling data integration amongst many plant disciplines within an operational plant environment.